Office de la propri^t6 Canadian 
intellectuelle Intellectual Property 

du Canada Offic 



Un organisme 
d'Industrie Canada 



An Agency of 
Industry Canada 



Certification 

La presente atteste que les documents^ 
ci-joints, dont la liste^figufe ci-dessous, 
sont des copies authentiques des docu- 
ments deposes au Bureau des brevets. 




Certification 

This is^to certify that the documents 
attatlied hereto and identified below are 
true copies of the documents on file in 
the Patent Office. 



Specification andDfawmgs, as originally filed, with Application for Patent Serial No: 
2,413,695, on December 6, 2002, by IBM CANADA LIMITED-IBM CANADA 
LIMITEE, assignee of Marcelo L. Patemostro and Marius Slavescu, for "Tracking Unit 
Tests of Computer Software Applications". 




>^gent ce^fificateur/Certifying Officer 



February 13, 2003 

( . Date 



Canada 



OPIC 



(ClPO 68) 
04-09-02 



CA 02413695 2002-12-06 



ABSTRACT OF THE DISCLOSURE 

[0089] The present invention provides a testing tool for testing software applications. 
The tool implements a method for tracking unit tests of a softwrare application, 
comprising conducting the unit tests on the software application, tiie unit tests ordered 
under hierarchical groupings; and tradcing tiie unit tests so as to capture a result of 
each unit test and a hierarchical position of each unit test witiiin the groupings. The 
method may further comprise outputting the hierarchical position of each unit test in 
association with the test result. If at least one of the unit tests is iterativeiy conducted 
multiple times, the method may further comprise, each time one of the unit tests is 
conducted, associating an iteration ordinal indication with a result obtained. The unit 
tests may be grouped within a test suite, which comprises a highest order grouping of 
the unit tests, tiie test suite grouping containing at least one test case, each test case 
comprising a sub-grouping of said test suite. 
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Tracking Unit Tests of Computer Software Applications 



REU) OF THE INVENTION 

[0001] The present Invention relates to computer software testing, partlculariy to 
software testing tools that track unit tests of software applications. 

BACKGROUND OF THE INVENTION 

[0002] Modem computer software applications ("applications") are often complex 
and require extensive testing. Testing of complex applications is typically conducted in 
different stages. Common stages of software testing include unit testing, component 
testing, functional testing, system testing and Integration testing. 

[0003] During unit testing, only one unit of an application is tested at a time. A unit 
may refer to any modular aspect of an application. For example, a unit could refer to a 
segment of code, a method In a class, or a function of an application. Often, multiple 
related units are tested together by using test cases and test suites. A test case Is a 
procedure verifying that one or more units of an application perfomr as Intended. For 
each tested unit, a test result, such as -pass" or lail," Is produced. A collection of test 
cases can be executed in an ordered sequence. Such a stmctured collection Is called a 
test suite. A test suite may also include one or more test suites. The structure of a test 
suite can be simple or quite complex. 

[0004] Many unit testing tools, such as JUnlt. have been developed In order to allow 
effective testing of units of a software applloallon. Other testing tools are used for each 
of component testing, functional testing, system testing, and Integration testing. While 
these various tools can be used to effectively test an application, this approach is not 
partlculariy efficient. 
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[00051 Theiei»needforaiT»«emcientmanner<,tte8ting«*«a«appl^ 

SUMMARY OF THE INVENTION 

raoofU Tl«p«sem invention proposes a software appUoatlontesanst^ 
L hle««=Ncal intonna«on o. unit tests behg exeo-ed and n^ also t™d< ite-a^ 
,„to„^ Of unit tests I«in9 executed. This additional lnlom»tio« alto«8 the un* tests 
to be used In testing laiger sections of an application. 

100071 in accordance with the purpose of the ltT«ntlcn. as en*o*^ 

described hereh, an aspect of «,e ln«ntlon is a method fo, tt^ldng un» t.*^^ 

software application, comprtsing con*icting the unit tests on the software app»cat»n. 
the «t tests ordered under hiererchical groupings; and tracking the 1e* eo a. » 
capture a result of each unit test and a hiererehlcal position of each test w*h,n the 

greuphfls. The method ma, further con^ the hlemichica. P<»«^ «« 

L assoclason with the test resun. I. at least one 0. the unH tests I»^ 

conduced mu«N* tknes, the n«thod ma, further comprtse. ea* *~ "« «^ T 
testa IS conducted, associating ^ Iteration ordinal indication with a result obtoied. The 
unit tests ma, t« greuped within a test suite. whk=h comprises a highest o^J^ 
of the unit tests, the le« suite greuping containing at least one test case, each te« case 

comprising a sul>-groupin9 of said test suite. 

,00081 Ano«,er aspect of the hventicn is a c«nputer readable meaum s,^ 
insm^tions, said ins,n«*« When executed b, a computer ^ a^^ 
c^puter s,stem to conduct the unit tests on the software applicat»«. the un* tests 
ordered under hierarchical greupings-. and treck the unH testa so as to capture a result 
of .«!h unit test and a hiererchical position of each unit test wttNn the greupmgs. 
100091 Yet aether aspect of the lnv««ion I. a oonH»*er .,«»T. for te*g a 
LJre app.^, oompr^ns a cenU.1 precslng unfc and ^ '^'^ 
.stn^Cions, sa^ lns.n:cUons. when executed b, sa« central precessN, uj* ^ 
said computer s,stem to conduct.heunH.ests on theso«wareappl«aton.theun*tesls 
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^ under hie,a,*teal ^upings; ,ndi«**eunl.t«.s8oastoc.pn«a«ul. 
„,eachunitlestandahie««cl*a.po«.iooo.eachun«t».«iWn««W 

LL appUcaHon, con,phslng .neans conducU,, unit - ^ «^ 
X«on.l un* teste «d«ed undar g~«P»^; a™i a»ans or ^ 

«^ .0 a. .0 cap.u« a 0. aa* u„» test and a hte««h«a, po^^on C 

Hr.es. *e ^.oup^ sys^n, «»y I 
ou.pu«iP9 «» hie«.*ioa. posBon of each un« *i a».c«»n *a Ha 

con,pr.se. each «me sa« one of said uni. .este IS «on*«*ad, rnaans .or aa««»^ 
Iteraton ordinal WicaSon wWi a rasi* oWained. 

en*«,i™ntt of in««n«on in ooniunoto wim aocon.^^ 

BRIEF OESCWPTION OF THE 0BAWIN6S 
(0012] in*etl8ure8iiiusUaan8exan,pteaa.bodinH»*sof1hap.e,en.i™^ 
POISI RGMieab.ocicdiaBBn.l«"*alinBaco«^<ersys.«"an*»dyln9aspa^ 

of the present invention. 

P0141 Ha2isablookdia9«.nillusUa«n9aponionof»«co«*uW8),sten.rf 
1. 

100,6] FH. 3 iilu^ates ma hierarchy Of an axempianf tes. executebie on «.e 

computer system of Fig. 1 . 

P016] FIG. 4 Shows a UI^L (Universal Modeiing Unguafle) diagran, 
iHustraang aspecte of a known testhg framewoifc 

10017] F«.5showsa«=.^sho.ofsan,pi.«su«.C«»»3««"=*-^«»*<' 
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using the f ram work of Fig. 4 with a textual test runner. 

[0018] FIG. 6 shows a screen shot of sampi results of the test of Fig. 3. also tested 
using the framework of Fig. 4 but with a graphical test mnner. 

[0019] FIG. 7 is a UML diagram illustrating aspects of the present inventfon. 

[P020] RG. 8 illustrates exemplary computer code implementing an aspect of the 

present inventton. 

[0021] FIGS. 9A-9B illustrate exemplary code implementing another aspect of the 
present invention. 

[0022] FIGS. lOA-lOB illustrate exemplary code Implementing yet another aspect of 
the present invention. 

[0023] FIG. 11 shows a screen shot of sample results of the test of Fig. 3. tested on 
the computer system of Fig. 1 . with the textual mnner of Fig. 4. 
[0024] RG. 12 shows a screen shot of sample results of the test of Fig. 3. tested on 
the computer system of Fig. 1 , with the graphical mnner of Fig. 5. 

DETAILED DESCRIPTION 
[0025] In the drawings and the following description, like parts are given like 
reference numerals. 

[0026] Referencing Rg. 1 . a computer system 1 00 embodying aspects of the present 
inventton may be optionally linked to a network 102. Computer system 100 may interact 
with other networked computer systems (not shown) to provide software applfcation 
testing In a distributed manner. However, for the sake of clarity and conciseness, 
aspects of the present invention are ilkistrated as embodied solely on computer system 
100 threughout the description herein. As will be appreciated by those of ordinary skill .n 
the art. aspects of the invention may be distributed amongst one or more networiced 
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compuUng devices, which communicate and Interact with computer system 100. via one 
or more data networlts such as network 102. Network 102 may be embodied using 
conventional network technotogies and may Include one or more of the following: local 
area networks, wWe area networks, intranets, the Internet, wireless networks, and the 
5 like. 

[00271 Computer system 100 has a central processing unit (CPU) typically 
comprising a processor 104, which communkjates with memory 106, input 108 and 
output 110. Processor 104 executes inslnictions stored in memory 106. 

[0028] Memory 106 includes a primary electronic storage for processor 104 and may 

10 include one or more secondary stores, each of whfch comprises a computer readable 
medium. A computer readable medium can be any available media accessible by a 
computer, either removable or non-removable, either volatile or non-volatile. Such 
computer readable medium may comprise random-access memory (RAM) or read-only 
memory (ROM), or both. A RAM may be dynamto (DRAM) or static (SRAM). A ROM 

15 may include programmable ROM (PROM), erasable PROM (EPROM), and electrically 
erasable PROM (EEPROM) such as Flash Memory. By way of example, and not 
limitation, computer readable media include memory chip, memory card, magnetic 
cassette tape, magnetfc cartridge, magnetic disk (such as hard disk and floppy disk, 
etc.). optical disc (such as CD-ROM. CD-R, CD-RW, DVD-ROM, DVD-R. and DVD- 

20 RW), Flash memory card (such as CompactFlash and Smartl^la card), memory stick, 
solid-state hard disk, and the like. Computer readable media also include any other 
magnetic storage, optkjal storage, or solid state storage devices, or any other medium 
which can embody the desired computer executable instmctions and can be accessed, 
either locally or remotely, by a computer or computing devtee. Any combinatton of the 

25 above should also be included in the scope of computer readable medium. 

[0029] Input devfce 108 may comprise, for example, a keyboard, a mouse, a 
microphone, a scanner, a camera, and the like. It may also include a computer readable 
medium and the conresponding devtee for accessing H. 
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10030] Output device 110 may comprise, for example, display devices, printers, 
speakers, and the lilce. It may also includ a computer writable medium and the device 
for writing to it. 

[00311 It will be understood by those of ordinary skill in the art that computer system 
ICQ may also include other, either necessary or opttonal, components not shown in the 
figure. By way of example, such other components may include elements of a CPU; 
networi( devtees and connections, such as modems, telephone lines, network cables, 
and wireless connecttons; additional processors; additional memories; additional input 
and output devtees; and so on. Further, two or more components of the computer 
system 100 may be embodied in one physteal device. For example, a CPU 104 chip 
may also have built-in memory 106; a hard disk can be part of the memory 106. input 
devtee 108. and output devtee 1 10; and a touch screen display is both an input and an 
output devtee. 

[0032] Referencing Fig. 2. stored on memory 106 are computer executable 
instructkjns for testing software appltoalfons 202. The Instmctlons comprise testing tools 
204 designed and implemented to facilitate the creation and execution of tests 206. 
Testing tools 204 may comprise an applteatlon package commonly known as a testing 
framewori<. Many conventional testing frameworics have been developed for creating 
and executing test cases and test suites. JUnit. for example. Is a Java unit testing 
f rameworic for creating and executing test cases and suites for Java applications. Other 
frameworics include for example MinUnit for C. CppUnit for C++, and NUnit for net 
applicatfons. Testing tools 204 may include one or more test runners 208. A test mnner 
208 is a tool that toads and executes the tests 206 and outputs the test results 212 to 
output device 110. 

[0033] Tests 206 are designed to test a portion or the whole of an application 202. 
often referred to as the subject under test 210. THe subject under test can be any 
aspect of the appltoation 202 a tester wishes to test. For example, to test a multi-user 
applteatlon. one subject under test could be a togin procedure. Test 206 may comprise 
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one or more unit tests 214. each of which tests only one modular aspect of the subject 
undertestFor xample. if the subject under test Is a login procedure, one unit t st214 
may test the opening of a dialog window and another unit test 214 may test the inputting 
of user name and password. To test a complex application, many, sometimes 
hundreds, of unit tests 214 may be used. Typically, multiple unit tests 214 within a test 
206 are ordered under hierarchical groupings according to their relationship. 

[00341 Fig. 3 illustrates the hierarchy 300 of an exemplary test. TS 302. Test TS 302 
includes three unit tests. A, B. and C. executed In the following ordered sequence, 

ABC ABCC A ABCABCABCABCABC ABCABC. 

Each of the unit tests A. B and C can be an operation designed to test an aspect of the 
subject under test. For example, if the subject under test is a login procedure, unit test A 
could test the code for opening a login dialog window, unit test B could test the code for 
receiving Input for a user name and a password, and unit test C could test the code for 
verifying or validating the user name and password. 

[0035] As is customary, the unit tests are represented in hierarchical groupings in 
hierarchy 300. Under the top node TS 302 of the hierarchical tree 300. there are five 
nodes, tests T1 304, T2 306, T3 308, T4 310 (repeated five times), and T1 312 
(repeated twice). One may consider test TS 302 as the parent of tests T1 . T2. T3. and 
T4. 

[0036] Test Tl 304. 312. 316. and 322 has three children, unit tests A. B. and C. 
Test T2 306 has two children, test Tl 316 and unit test C 318. Test T3 308 Is the parent 
of one test, unit test A 320. Test T4 310. which is repeated five times, also has one 
child, test Tl 322. White test T1 is consecutively executed seven times in tests T4 310 
(Tl 322) and Tl 312. the last two iterations fTI 312) are distinguished from the previous 
five iterations (Tl 322) because they have different parents. T4 310 and TS 302. 
respectively. 

p)037] Iteration of a test is often necessary for a number of reasons. A system may 
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require a load and stress test, in which the same action is repeated hundreds of times in 
a given time period to checit if the system can handle the load, it may also be of interest 
to test how a database system would react when two entries are added to the database 
with the same primary key. Two iterations of the same test do not necessarily produce 

5 the same result due to changes in test environment or test parameters. For example, A 
test may fail only on even numbered iterations due to a bug in the code. In the login 
example described above, unit test C 314 may pass or fail depending on the input 
received in the preceding test, unit test B, which may be passed as a parameter to unit 
test C or cause a certain change in the system environment. (In principle, however, the 

10 result of a unit test should not depend on the pass or failure of a preceding unit test.) 
For example, unit test C may fail because the usemame or password consists of 
unacceptable characters. In a client-sen/er application, unit test C may also pass the 
first time but fail the second time if, during the inten^l between the two iterations, the 
senrer has crashed, or a communication channel between the client and the sen/er has 

15 become so congested that a time-out has been reached before a response can be 
received. 

[0038] Tests 206 such as TS 302 may be implemented using test cases and test 
suites. A test case describes the subject under test and items to be tested. A test case 
may comprise one or more unit tests, test cases or a combination of both. A test suite is 
20 essentially a collection of test cases. Thus, tests T1 , T2 . T3 and T4 are test cases and 
test TS is a test suite. 

[0039] From the above description, it may be appreciated that each node of the test 
hierarchy 300 is a test: the top node is a test suite; the intemiediate nodes are test 
cases; and the tenninal nodes are unit tests 214. Each unit test 214 descends from a 
25 chain of nodes forming a branch of the hierarchical tree 300. For ease of description, a 
branch of a hierarchy is represented herein with a text string of the following forniat: 

TestSuiteName_#>TestCaseName_#>. . .>UnltTestName_#, 
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where TestSuiteName is the name of the test surte at the top node, TeslCaseName is 
the name of the test case at an jntennediate node, UnitTestName Is the nam of the 
unit test at the temiinal node, and # is an iteration ordinal indication, which can be m 
integer or other sequential numbers. The test preceding a V sign is the parent of the 
5 test following the V sign. Thus, for instance, the first branch of hierarchy 300 (that is. 
the execution of unit test A in test T1 304) is represented as 'TS_1>T1_1>A_1" and the 
third Iteration of unit test B In T4 310 is represented as 'TS_1>T4_3>T1_3>B_3". 

[00401 Test cases and test suites are generally Implemented using test scripts. While 
test cases and test suites can be implemented In any scripting or programming 
10 language compatible with the particular testing tools used, In this description, exemplary 
test cases and test suites are implemented using test scripts In Java language for 
illustrative purposes. 

[0041] To assist the understanding of the exemplary embodiments of the present 
invention described herein, a brief description of a known JUnit frameworit is given next. 

15 [0042] Referencing Rg. 4, the two main classes of the known JUnit frannewori^ are 
the TestCase class 402 and TestSuite class 404, both of which implements the Test 
interface 406. Test Interface 406 specifies the methods that a conforming class must 
define. Including methods for nmning a unit test and for collecting test results in an 
instance of TestResult 408. 

20 [0043] Within the JUnit frameworit, test cases are defined using the TestCase class 
402, which encapsulates the togfe of a test case and has, among others, the foltowing 
methods: 



TestCase class 


Method 


Comment 


Test methods 


Each method implements the logic of a unit test. 

If a TestCase class does not provide a suiteO method (see 
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below), all test methods in the class whose names start with 
"tesf are executed In the sequence of their creation. 


suit 


Allows execution of selected test methods in the class and 
execution of other test cases or test methods in other 
TestCase classes. 

Test cases can be recursively composed of cases of cases 
using the "suite" method. 


run 


Executes this test and collects the results with a default or 
specified TestResult object. 


runTest 


Run a test and assert its state. 


setName 


Sets the name of a test case. 


getName 


Gets the name of the test case. 


toString 


Returns a string representation of the test case. This string 
contains the name of the test object and its source. 



[0044] The TestSuite class 404 is used for implementing test suites. A test suite is a 
composite of tests. It runs a collection of test cases. An Instance of TestSuite 404 can 
mn only tests specifically added to the suite or can extract the tests to be run 
automatically from a specHied test class. TestSuite class 404 has. among others, the 
following methods: 



TestSuite class 


Method 


Comment 


addTest 


Adds a test case or a test method to the suite. 


addTestSuite 


Adds all the test methods in the specified test class to the suite. 


testCount 


Returns the number of test cases In the suite. 



[0045] The TestSuite class also has methods similar to those in the TestCase class, 
such as "mn', -oinTesP. "setName", "getName". and "toStringf etc. 
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[0046] As alluded to above, the results of a test are placed in a TeslResult object. 
The conventional JUnit framework comes with different Implementations of TestResult. 
The default implementation counts the number of failures and errors and collects the 
results. For example, the TeslResult class 408 may be instantiated to collect the results 
and present them In a textual fonn (see Fig. 5). The UlTeslResult dass may be used 
by graphical test runners to update the graphical test status (see Fig. 6). 

[00471 Retuming to Rg. 3, test T1 may be implemented in Java as a test case for 
use with JUnit. using the exemplary code partially Illustrated m Appendix I. As Illustrated, 
class T1 is a subclass of the TestCase class 402. In class T1, a Test named Tl' Is 
defined. Test Tl includes three unit testa A. B, and C. which are respectively defined in 
class Tl as methods A, B and C. It Is understood that one or more of the methods 
implementing unit tests A, B. and C may be defined In another class or test script. 

[0048] In order to demonstrate the operations of the known JUnit and the 
embodiments of this invention, two failures are arbitrarily Introduced to test TS 300. one 
at TS_1>T4_5>T1_5>B_5, which is the seventh execution of unit test B, and one at 
TS_1>T1_2>C_2, which is the tenth execution of unit test C. The two failure conditions 
are implemented in method B and method C of class T1 as partially illustrated In 
Appendix I. As conventional in the field of software testing, an error is distinguished 
from a failure in that, while both will cause the test to fail, a failure is anticipated (often 
Intenttonally introduced by the test designer) whereas an error is unexpected. 

[0049] Similarly, one can define test case T2, which executes test case Tl and unit 
test C as defined by method C in class Tl (as conventional in Java language, method C 
of dass T1 may be referred to as T1.C") using exemplary code partially illustrated in 
Appendix II; test case T3. whtoh executes method T1.A, as illustrated in Appendix III; 
and test case T4. whfch executes test case T1 five times, as illustrated in Appendix IV. 
Partial exemplary code implementing test suite TS is illustrated In Appendix V. 

[0050] As will be understood by a person skilled in the art. there are alternative ways 
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of implementing test TS 302. For instance, the methods implementing unit tests A. B 
and C may be defined in a test script other than the one that implements test case T1 . 
or in a TestCase class other than the T1 class, so long as the argument of the "addTesf 
method points to the correct test class. Further, as mentioned, if a method in a test case 

5 class has a name starting with "tesf . e.g. -lestA", H will be automatically included in the 
suite when the class is added to the suite using the addTestSuite method. Thus, it is not 
necessanf to explicitly add each test case or unit test to the suite using the addTest 
method. Repeated tests can also be alternatively Implemented. For example, instead of 
using RepeatedTest method, consecutive addTest statements may be used. In addition. 

10 the T4 test case may invoke the RepeatedTest in the argument of "addTest". instead of 
invoking it in the "return" statement. 

[00511 From the exemplary code illustrated, it may be appreciated that for each 
branch of the tree 300, the tests are executed sequentially from the top node to the 
temiinal node, where when the test at each node Is executed, a new ot)ject 
15 implementing Test 406 is instantiated. The top node is an instance of the TestSuite 
class whereas the lower nodes are instances of the TestCase class. 

[00S2] Conventtonally, unit test frameworks provide test results which indicate 
whether and how many failures and errors have occuned during the execution of a test 
suite. For example, the existing JUnil frameworic provides results of tests through 
20 instances of the TestResult dass 408. Figs. 5 and 6 illustrate example screen shots 500 
and 600 of the results of executing the exemplary test suite TS 300, as implemented 
above, on a known JUnH framewori.. Fig. 5 shows the result of mnning the test with a 
textual mnner. Fig. 6 shows the result of mnning the test with a graphical mnner. In both 
cases, rt Is Indicated that two failures had oocuned (see text blocks 502 and 602). 

25 [00831 The identification of the test methods that failed provides sufficient infomiation 
to altow for effective unit testing. However, we have recognized that the test cases and 
test suites created for unit testing can be used in higher level testing, e.g., in one or 
more of component testing, functional testing, system testing and integration testing. If 
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the locations of the unit test failures are precisely provided. Existing unit test 
frameworks do not provide this Information dearfy. conveniently and efficiently. For 
example, the test results provided by existing JUnIt do not explicitly indicate where In 
the execution hierarchy and which iteration of a test produced a failure. 

5 [0054] As illustrated in Fig. 5. the result 500 explicitly indicates that two failures have 
occuned (see text blocks 502). It also indicates (see text blocks 504) that one failure 
oocuned during an execution of unit test B (as implemented in the method TLB) and 
another during an execution of unit test C (as implemented in the method T1.C). 
However, since unit test B Q.b. method TLB) Is executed nine times and unit test C 

10 (method T1 .C) ten times In TS 302, It is not clear exactly at which branch and which 
iteratkjn the failures occurred. While one may count the dots In text block 506 (where 
each dot represents a test mn and an "P indteates a failure) and calculate the exact 
location and iteration of the failed tests, this is very inconvenient even In simple tests. It 
becomes impractical when the test has a compltoaled structure and includes hundreds 

IS of iterated unit tests. 

(0055] Fig. 6 shows a sample result 600 of the same test executed with a graphical 
runner. Text block 602 indteates that there are two failures. In addition, the result 600 
includes a graphteal representation of the test hiemrchy 300. on which the failure 
locations are indicated as crosses 604. As shown, one failure occurred at 
20 TS_?>T4_?>T1_?>B_? branch and the other at the bottom TS.?>T1_?>C_? branch. 
However, from this result. It is not dear at whfch iterations the failures occurred. 

[0056] Detemiining the failure location and iteration is not overly problematic for 
many testers at the early stages, particularly the unit testing stage, of application 
devetopment. The structures of tests at an early stage are usually simple and the 
25 testers usually wrote the test scripts and the code for the subject under test themselves 
or were othen»»l8e intimately involved in tiie development of the test scripts and ttie 
appllcatten code, so that they know the structures of the tests quite well and it Is not 
difficult for them to figure out the exact location of a partteular failure. However, at the 
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later testing stages, the test suites often hav complex structures and the testers often 
do not know the test scripts, nor the cod of the appllcalfon under test, well enough to 
independently identify failure locations. 

[00571 Thus, in order to use existing unit testing tools and test scripts in the later 
5 stages of testing, it is desirable to modify the existing unit testing tools to provide dear 
indications of failure location. A possible approach to do so is to modify the test runners 
208. A given test may be mn with different mnners. While the test results are runner 
independent, the visual representation of the test results may vary from runner to 
runner, as already illustrated above and in Figs. 5 and 6. It is therefore possible to 
10 constmcl mnners that provide the desired failure infomialion. again as partially 
demonstrated in Figs. 5 and 6. 

[0058] However, modifying runners has at least three drawbacks. First, to provWe 
this additfonal information, all existing mnners have to be modified. Second, the 
modifkjation of a mnner can be expensive, difftouit, and even impractical such as when 
15 the source code of the mnner is unavailable. Third, as each mnner developer may 
choose its own representation of the desired Infomiation. the representation fomnats 
may not be uniform. It is therefore preferable to provide «ie desired additional 
information witiiout reliance on test mnners. 

[0059] Embodiments of the present invention include testing tools that provide a way 
20 of tracking unit tests so as to capture the hierarchical infonnation and iteration 
information without tiie need to modify existing mnners. 

[0060] In the exemplary embodiments of the present Invention described below, a 
known JUnit framework (referred to as non-extended JUnit hereinafter is extended to 
Include methods for capturing the name of the current test, the name of «ie parent of 
25 the current test, and the ordinal number of the iteration of the current test (the modified 
frameworit is referred to as the extended JUnit hereinafter). The infomiation is captured 
before each iteration of a test case is executed. The captured infomiation is then 
embedded in a text string ttiat represents the current test case. Since the string 
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representing the test case is by default included in the test result held by the TestResult 
object, the informalion is transparently passed on to the test runner and will be 
displayed in a uniform manner, which may be enforced by the extended Test interface. 
This and other advantages of this approach can be appreciated by a person skilled in 
5 the art from the following description. 

[00611 A particular Implementation of this approach is described next. In the 
following, exemplary modifications are described using example source code. However, 
some portions of the source code are not explicitly described or explained because 
persons skilled in ttie art would understand ttie functions of these portions, that these 
10 functtons should or may be included, and the manner In whteh these functtons may be 
implemented. For example, it would be understood ttiat It is a good programming 
practice to check for a null siring before perfom^ing an operation on a siring. 

[0062] In this particular implementation, two classes, the TeslCase class 402 and the 
TestSuite class 404 are modified (extended), as illustrated In Fig. 7. From Fig. 7. it will 
15 also be apparent tiiat ttie Test interface 406 may be modified. 

[0063] Specifically, the interface lExtendedTesl 706 defines ttie extended Test 
interface (extending the interface Test 406). An exemplary code 800 Implementing 
interface lExtendedTest 706 Is Illustrated In Fig. 8. This exlenston ensures ttiat all 
implementations of interface lExtendedTest 706 would be compliant with tiie extended 

20 JUnit (witii the additional infomriation about the parent, ttie cunent iteration ordinal and 
the name of the test embedded in the string representing the test (toString)) regardless 
of whether ttie test mnner used implements the extended features. Thus, all existing 
mnners of non-extended JUnit may be used with ttie extended JUnlt without 
modifteation. However, existing test scripts created witii non-extended JUnit need to be 

25 modified In order to implement lExtendedTest interface 706. The modifications are 
nonettieless quite simple and can be automated as will become apparent from tiie 
following description. 

[0064] As is understood by persons skilled in ttie art. In Java language, an Interface 
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specifies the methods each oonfomiing class must define. Referring to exemplary code 
800 in Fig. 8, mterfac lExtendedTest 706 specifies the methods that must be defined in 
each test class. Text btock 802 (line 8) specifies a method that sets the parent for the 
current test (setParent); block 804 (line 10) specifies a method that returns the name of 
5 the parent (getParent); block 806 Oine 12) specifies a method that returns the current 
iteration ordinal indication of the current test (getlteration); btock 808 (line 14) specifies 
a method that returns the name of the current test (getName); and btock 810 (line 16) 
specifies a method that defines a new string (toJUnitStrIng). the use of whteh will 
become clear below. 

10 [00651 Referring to Figs. 9A-9B. the extendedTeslSufte class 704 imptemented in 
the exemplary code 900 extends the TestSuite class 404 to provWe the expected 
behavior specified in the lExtendedT est 706 interface. 

[0066] Specifically, the methods of setParent (text block 902). getParent (btock 904), 
and getlteration (block 906) are added. Further, three methods addTestSuite (block 
15 908), addTest (block 910). and njnTest (btock 912) are redefined. Redefined mnTest 
(block 912) now executes a new. added method adjustlteration (block 914). The string 
representing test cases is defined using a redefined toString method (btock 918). whtoh 
in turn includes a new string hIerachyBranchToString (btock 920). The above 
modifications provide the methods to capture the desired additional information. 

20 [0067] li/lore specifically, the redefined addTestCTest) method (block 91 0) first calls 
the addTest method defined in the unextended TestSuite class and then sets the 
current test suite as the parent of the added test, if the added test implements the 
lExtendedTest interface (line 44. as understood by persons skilled in the art, in Java 
language If an object is an InstanceoT an interface then the object imptements the 

25 interface). As can be appreciated, a test suite is transparentiy set as the parent of any 
test case executed by the test suite. 

[0068] The redefined runTest method (block 912) sets the iteration ordinal of a test 
before actually running the test, using the following logte (see block 91 4). 
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[0069] The rteratlon counter (Iteration") of the cunrent test is calculated as (line 70- 
73): 

fint(executioiiCount/testCount), if mod(executionCouiit/testCount)=0 



Where testCount is the number of tests to be executed in the current test and 
executionCount Is the number of tests that have already been executed. The 
executionCount is Incremented by one before each execution of a test (line 70). For 
example, in Fig. 3. test T1 (312) has three children, thus. testCount * 3. Assuming that 
unit tests A and B have been executed once each, executionCount = 2. Therefore, 
iteration = Int (2/3) + 1 = 1 (since mod(2/3)=2), which means It Is the first Iteration of T1 . 
Next unit test C is executed and executionCount = 3, then Iteration = (3/3) = 1 (since 
mod(3/3)=0). It Is still the first Iteration of T1. The next execution Is the second 
execution of unit test A and fourth overall. Hence, executionCount = 4 and iteration = 
int (4/3) +1 = 2. It is the second rteratlon of test T1 . 

[00701 The execution counter Is set to zero when a new object of ExtendedTextSuite 
604 Is Instantiated (line 14). The execution counter Is also reset to zero when the 
current test has a parent which implements lExtendedUnlt test and whose Iteration 
counter has changed since last time the Iteration counter of the cunent test was set 
(lines 60-68), This ensures that the Iteration ordinal of the current test wIM be reset to 1 
when the parent test begins a new Iteration. For example, assuming that TS 302 Is 
iterated twice, when TS 302 begins its second iteration, the execution counter of T1 
(312) would be reset so that the counter only counts the tests that have been executed 
during the second iteration of the parent, test TS 302. 

[00711 As will be understood by a person skilled in the art, the logic described above 
is merely one of many possible ways of calculating or tracking the Iteratfon ordinal 
Indication of tests. This togic, and its partksular implementatton illustrated herein, is 
described only for lllustratton purposes. 

[00721 When each test Is executed, or In other words, when each test obiect is 
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instantiated, the parent and iteration infonnation about the test is embedded in the 
standard Java output siring toString representing the test object. During execution, any 
time when a system output from the test object Is requested, the toString method of the 
test object Is called (executed). The content of the toString as defined In the unextended 
TestSuite dass is presented in the toJUnitSlring (blocks 916). The redefined toSring 
method In the extendedTestSufte dass returns a new siring called 
hierarchyBranchToString (block 918). The siring returned by 
hierarchyBranchToString(currentTest) is oonstnicted simllariy for both test cases and 
test suites, as follows (block 920). 

[0073] If ther© is a parent, the parent's hierarchyBranchToString (i.e., 
hierarchyBranchToString(parent) is added to the string (line 91) followed by a V sign 
(lines 92-93). If there is no parent, nothing is added. In either case, the name of the 
currentTest is added to the end of the string (line 95). If the iteratton of the cunentTest is 
greater than zero (i.e., it has been executed at least once), a "_" sign Is added and 
followed by the iteration ordinal (lines 96-97). The string is then returned as 
hierarchyBranchToString(cun-entTest). For example, H the cunent test is the first 
rteration of TS 300, there is no parent and the hierarchyBranchToSlringfTS) wouW 
retum a string 'TS.r. Next, test case T1 304 is executed, hierarchyBranchToStringfTI) 
would retum a string 'TS_1>T1_r. The next test to be executed is unit test C 314. The 
parent is T1. and the string returned would be •TS_1>T1_1>C_r. The string is only 
constmcted this way when the current test implements lExendedTest (lines 88-100). 
Othenwise, the string returns "?>" followed by the default toString of the cun-ent test. For 
example. "?>teslD". 

[0074] Referring to Fig. 10, the extendedTestCase class 702 implemented In 
exemplary code 1000 extends the TestCase dass 402 by, in part, defining the methods 
setParent (block 1002) and getParent (block 1004) and the siring methods toJUnltSlring, 
toString, and hierarchyBranchToString (lines 43-68) simllariy as In the 
exlendedTestSuite class 704. However, the gettteratton method (btock 1006) Is defined 
differently. The iteration of a test in a test case is set the same as its parent if the parent 
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has a non-null name and is an instance of the extendedTestSuit dass (lines 32-33). 
Olhenwise, the iteration cannot be calculated and is Initially set to minus one (-1) (line 
35). This method provides a convenient way of getting the Iteration count from the 
parent. 

5 [0075] As can be appreciated, in this exemplary embodiment, the iterations of tests 
in a test case is not separately and individually tracked and captured. Tests in test 
cases inherit iteration counts from their parents. It is possible to also traci^ and capture 
iteration ordinal indications of tests in test cases separately and individually, which can 
be easily implemented by a person skilled in the art using a logic similar to that for the 

10 test suite. However, while other embodiments are possible, the exemplary embodiment 
described above has several advantages. It encourages the test designers to adhere to 
a design principle of JUnit framework: use test cases for simple grouping of unit tests 
and use test suites for complex groupings and repetitive testing. It is also easy to 
implement. 

IS [0076] The captured parent and iteration information may be represented and 
passed to the output 1 10 in other manners as well. For example, the string representing 
the test object (toString) may be formatted differently as described above. A nwre 
specific example Is that the signs ">" and may be replaced with any other suitable 
symbols, lettere, words, or combinations of these. While decimal integere are 

20 convenient to use, the iteratton ordinal indteation may be represented by other 
sequential symbols instead of Arabic numbers or in other counting systems instead of 
the decimal numbers. For example, letters or binary numbers may be used. TTie test 
object may also be represented in whole or in part in graphical form. One advantage of 
the embodiment described above is that the Information is presented or displayed in a 

25 unifonn manner on different output devices 110 and with different test njnners 208. 

[0077] As can be appreciated, the modification to the JUnit framework is minimal and 
can be easily implemented. Since both parent and iteration information is captured and 
recorded transparently there is no need to modify existing test runners in order to use 
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them to run tests under the extended JUnit. There is also no need to add additional 
code to existing test scripts for the scripts to be executable under the extended JUnit, 
except for modifications to invoke the three extended classes Instead of the non- 
extended classes, as will be described next. 

[0078] Modification of test scripts created under the non^xtended JUnit for 
execution under the extended JUnll Is simple and straightfonward. For example, the 
following table summarizes the changes made to the exemplary code of Appendices I to 
V. in order to Implement test TS 302 for execution under the extended JUnit described 
herein. The resulting exemplary code Is partially Illustrated In Appendices VI to X. 



Type of modification 


TestCase Class 


TestSuite Class 


Modify package name 


new name: extendedTTests 


new name: extendedTests 


New Imported Java files 


ExtendedTestCase; 
ExtendedTestSuite 


ExtendedTestSuite 


Replace any new TestCase 
dass with ExlendedTeslCase 
class 


Replace TestCase" with 
-ExtendedTestCase" in 
each phrase that contains 
"extends TestCase" 




Replace any new instance of 
TestSuite class with instance 
of ExtendedTestSuite class 


Replace "TestSuite" with "ExtendedTestSuite" in each 
phrase that contains "new TestSuite" 



[0079] As can be appreciated, these modifications of the test script can be 
automated by replacing certain lines of code, adding new lines of code, and replacing 
certain phrases. 

[0080] Other modifications to these and other classes of the JUnit and the test 
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10 



15 



20 



25 



scripts may t>e made to provide additional features, additional functionality, or 
convenience, as will be understood by persons skilled In the art. 

[0081] The results of executing TS 302 using the extended JUnit are shown In Figs. 
11 and 12. Fig. 11 shows the screen shot 1100 of results of the test executed by the 
textual runner of Fig. 5. Fig. 12 shows the screen shot 1200 of results of the test 
executed by the graphical runner of F.g. 6. As can be seen, the parent and iteration 
Infomiation is clearly presented in text blocks 1 102 and 1202. 

[0082] While in the exemplary embodiments described above, the Test interface 406 
has been modHied, this modifteation is not necessary, as long as all test suites and test 
classes Include the methods defined in the lExlendedTest 706 interface and appropriate 
changes are made to the exlendedTestSuite 704 and extendedTestCase 702 classes. It 
is. however, a good programming practtee to modify the interface to enforce the 
behavtor of conforming classes. 

[0083] The embodiment of this invention is described above in the context of test 
failures. However, the captured hierarchical and iteration infomiation may be used in 
other contexts or associated with other events of testing. 

[0084] In the exemplary embodiments described above, for simplteity reasons, the 
iteration indicator of a test only indfcates the number of consecutive executions. Non- 
consecutive executions are not distinctively Identified in the output. For example. T1 304 
is not differentiated from T1 312. The first execution of either one of them is represented 
by the string 'TS_1>T1_1." It is possible to include, e.g. in toString. an indication of ttie 
number non-consecutive executions of a test, such as TS_1>T1(1)_1- for T1 304 and 
TS_1>T1(2)_1"for T1 312. 

[0085] As will be appreciated, tiie exemplary extended testing framewotk described 
herein provides clear, precise, and consistent representation of the hierarchical and 
iteration infomiation of unit tests, without the need to modify test mnners. The additional 
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hierarchical and Iteration information is readily available at any steps of the execution. 
Implementing the extended testing framework is simple and straightforward. Therefore, 
xisting unit testing tools and unit test scripts can be used In a higher testing stage such 
as component testing or system testing with easy and minimal modifications of the unit 
testing framework and test scripts. 

[0086] Other features, benefits and advantages of the present invention not 
expressly mentioned above can be understood from this description and the drawings 
by those skilled in the art. 

[0087] Although only a few exemplary embodiments of this invention have been 
described above, those skilled in the art will readily appreciate that many modlfteations 
are possible therein without materially departing from the novel teachings and 
advantages of this inventton. Accordingly, all such modifications are intended to be 
included wHhin the scope of this Invention as defined in the following claims. In the 
claims. meansi)lus.funclion clauses are intended to cover the structures described 
herein as perfonning the recited function and not only structural equivalents but also 
equivalent structures. 
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Appendix I. Portion of an exemplary test script for TestCase class T1 . 
packa^ tests 

public class Tl extends TestCase 
{ 

private static int bCounters=0; 
private static int cCounter=0; 

public static Test soiteO 
{ 

TestSuite testSuite = new TestSuiteCTn: 
testSuite.addTest (new T1("A")); 
testSuitcaddTest (new T1("B")); 
testSuite-addTest (new T1("C')); 
return testSuite; 

} 

public void AO 

/* define operation of unit test A */ 

} 

puUicvoidBO 
{ 

bCounter++; 
if(bCounter=7) 

assertNotNull("Enor introduced at a specific context of the test B", null); 
/* define other operation of unit test B */ 

} 

puUic void CO 
{ 

cCounter++; 
if(cCountffl:=10) 

assertNotNullC'Error introduced at a specific context of the test C , null); 
I* define other operation of unit test C */ 

) 

1 
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Appendix II. Portion of an exemplary test script for TestCase class T2. 

• • • 

public class T2 extoids TestCase 
{ 

5 

public static Test suiteQ 
{ 

TestSuite testSuite = new TestSuite('T2"); 
testSuite-addTest (Tl.suite()); 
10 testSoitejiddTest(iiewTl("C")); 
return testSuite; 

1 

1 

15 Appendix III. Portion of an exemplary test script for TestCase class T3. 

public class T3 extends TestCase 
{ 

20 public static Test suiteO 

^ TestSuite testSuite = new TestSuite('T3*'); 
testSuite-addTest (new T1("A")); 
return testSuite; 

25 } 
} 

Appendix IV. Portion of an exemplary test script for TestCase class T4. 

public class T4 extends TestCase 
30 { 

public static Test suiteQ 

* TestSuite testSuite = new TestSuiteCT4"); 
35 testSuite-addTest (Tl.suiteO); 

return new RepeatedTest(testSuite, S); 

} 

) 
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Appendix V. Portion of an exemplary test script for TestSult class TS. 

public class TS extoids TestSuite 
{ 

5 

public static Test suiteQ 
{ 

TestSuite testSuite = new TestSuite(*TS"); 

10 testSuite.addTest(Tl.suiteO); 

testSuitcaddTest (T2.suite()); 
testSuite-addTest (T3.suite()); 
testSuite.addTest (T4.suite0); 
testSuite-addTest (new RepeatedTest(Tl.suite(), 2); 

15 

return testSuite; 

} 

public static void main (StringQ arguments) 
{ 

20 /* ^ 

* some statements for invoking a sdected test runner to run the test TS 

*/ 



} 



25 
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Appendix VI. Portion of an exemplaiy test script for ExlendedTestCase class T1 . 
package sstgui^Tests; 

import extended-ExtaidedTestCase: 
im port extended.ExtendedTestSuite: 
public class Tl extends ExtendedT estCase 
{ 

public static Test suite() 

' TestSuitetestSuite = newExtOTdetfrestSuite("Tl"); 
extendedTestSuitcaddTest (new T1("A")); 
extendedTestSuite-addTest (new T1("B")); 
extendedTestSuite-addTest (new T1("C")); 
retom testSuite; 

} 

public void A() 

{ 

• • • 

) 

public void BO 
{ 

} 

public void CO 
{ 



) 

) 
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Appendix VII. Portion of an exemplary t st script for ExtendedTestCase class T2. 

public class T2 extends ExtendedT estCase 
{ 

public static Test suite() 

^ TestSuitetestSuite = newExtsktedrestSuite('T2''); 
testSuite-addTest (Tl.suiteO); 
testSuite-addTest (new TIC'CT)); 
return testSuite; 

) 

1 

Appendix VIII. Portion of an exemplary test script for ExtendedTestCase class T3. 

■ • • 

public class T3 extrads ExtendedT estCase 

{ 

public static Test suiteQ 

^ TestSuite testSuite = new ExtendedT estSuite('T3"); 
testSuite-addTest (new T1("A")); 
return t^tSuite; 

) 

} 



Appendix IX. Portion of an exemplary test script for ExtendedTestCase class T4. 

• • • 

public class T4 extends ixt^gdrestCase 
{ 

public static Test suiteQ 

^ TestSuite testSuite = new Ex^MTestSuite('T4"); 
testSuite-addTest (Tl.suiteO); 
return new R^eatedTest(testSuite, 5); 

1 

} 
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Appendix X. Portion of an exemplary test script for ExtendedTestSurte class TS. 



imnort extende dExtendedTestSuite: 

public class TS extends ExtendedT estSuite 
{ 

public static Test suiteQ 
{ 

TestSuite testSuite » new is£aii|s^TestSaite('TS"); 

testSuite.addTest (TLsuiteO): 
testSuite.addTest (T2.suite()); 
testSuite.addTest (T3.suiteO); 
testSuite.addTest (T4.suiteO); 
testSuite.addTest (new RepeatedTest(Tl.suiteO,2); 

return testSuite; 

} 

public static void main (SttingQ atgumoits) 
{ 

r 

} 
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WHAT IS CLAIMED IS: 

1 . A method for tracking unit tests of a software application, comprising: 

(a) conducting said unit tests on said software application, said unit tests 
ordered under hierarchical groupings; and 

(b) tracking said unit tests so as to capture a result of each unit test and a 
hierarchical position of said each unit test within said groupings. 

2. The method of claim 1 further comprising outputthg said hierarchical posltton of 
said each unit test in associatton with said result. 

3. The method of claim 1 or daim 2. wherein at least one of said unit tests Is 
iteratively conducted multiple times and further comprising, each time saW one of 
said unit tests is conducted, associating an iteratfon ordinal indfcatfon with a result 
obtained. 

4. The method of any one of claims 1 to 3. wherein saW unit tests are grouped within 
a test suite, said test suite comprising a highest order grouping of said unit tests, 
said test suite grouping containing at least one test case, each test case 
comprising a sub-grouping of said test suite. 

5. The method of claim 4 wherein a sub-set of said unit tests is grouped within one 
testes^. 

6. The method of claim 5 wherein one or more other test cases are grouped within 
said one test case, each of said other test cases comprising a sub-grouping of 
said one test case. 
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7. The method of claim 6 wherein at least one of said other test cases is iteratively 
conducted. 

8. The method of any one of claims 3 to 7, wherein said tracking and said 
associating comprise instantiating at least one of a test case class and a test suite 
class, said test case class and said test suite dass being associated with 
methods for. in respect of a given unit test, getting a parent of a sub-grouping to 
which said given test belongs and any iteration ordinal. 

9. The method of claim 8 wherein said test case class extends a test case class and 
said test suite class extends a unit test suite class. 

10. The method of claim 9 wherein said unit tests are conducted by an instantiation of 
a mnner within an instantiation of a frameworic, said test case class and said test 
suite class being part of said f rameworic. 

11. The method of claim 10 wherein said framework and said mnner are JUnit 
compliant. 

12. A computer readable medium storing instructkms, said instmctkms when 
executed by a computer system adapting said computer system to: 

(a) conduct unit tests on a software application, said unit tests ordered under 
hierarchical groupings; and 

(b) track said unit tests so as to capture a result of each unit test and a 
hierarchical position of sakJ each unit test within said groupings. 

13. The computer readable medium of claim 12 wherein said computer system is 
further adapted to output sakl hierarchfcal positton of sakl each unit test in 
association with said result. 
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14. The computer readable medium of claim 12 or claim 13. wherein at least one of 
said unit tests is iteratively conducted multiple times and said computer system is 
further adapted to, each time said one of said unit tests is conducted, associate 
an iteration ordinal Indication with a result obtained. 

1 5. A computer system for testing a software application, comprising: 
a central processing unit; and 

a memory storing instructions, said instructions, when executed by s»d central 
processing unit, adapting said computer s^em to: 

(a) conduct unit tests on said software application, said unit tests ordered under 
hierarchical groupings; and 

(b) track said unit tests so as to capture a result of each unit test and a 
hierarchical position of said each unit test within said groupings. 

16. The computer system of claim 15 wherein said computer system is further 
adapted to output said hierarchical position of said each unit test in association 
with said result. 

1 7. The computer system of any one of claims 1 5 to 1 7, wherein at least one of said 
unit tests is iteratively conducted multiple times and said computer system is 
further adapted to, each time said one of said unit tests is conducted, associate 
an iteration ordinal indication with a result obtained. 

1 8. A system for tracking unit tests of a software application, comprising: 

(a) means for conducting unit tests on a software application, said unit tests 
ordered under hierarchical groupings; and 

(b) means for tracking said unit tests so as to capture a result of each unit test 
and a hierarchical position of said each unit test within said groupings. 
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19. The system of daim 19 further comprising means for outputting said hierarchical 
position of said each unit test in association with said result. 

20. The system of claim 18 or claim 19, wherein at least one of said unit teste Is 
itetatively conducted multiple times and further comprising, each time said one of 
said unit tests is conducted, means for associating an iteration ordinal indication 
with a result ot>tained. 
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IFAILURESL TEST HIERARCHY 












junit.framework.AssertionFailedErron Error Introduced at a speci 

attests2.T1.B(Tl.iava:60) , . „ „ „ * • o 
atiunit.extensions.TestDecorator.basicRun(TestDecoratorjava:Z 
at unit.extensions.TestDecorator.run|TestDecorator.java:28) 
atjunit.extensions.RepeatedTestrun(RepeatedTest.java:25) 












iFinished: 0.32 seconds 
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1 package jvinit; 
2 

3 import j\jnit. framework. Test; 
4 

5 interface lExtendedTest 

6 extends Test 

7 f 

8 public void setParent (Test parent) ; < 802 

9 

10 

12 piiblic int getlterationO ; 

14 piablic String getNameO; 
15 

16 p\iblic String toJUnitString { ) ; 

17 } 



pijblic Test getParentO; '804 

-806 

<^ 808 

^ ^810 
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1 package junit; 

import junit .extensions TestDecorator; 
imnort i unit . framework. Test ; 
iS^t junit . framework .TestResult ; 
j unit . framework .TestSuite ; 

SSdJ^Kst%^S?e^ XHxtenaedTest 
\l ^ private Test parent; 
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]i private int iteration =0; 

nrivate int executionCount = 0; 
It lAllle int previousParentlteration = 0; 

^7 public void setParent{Test parent) | 

11 ^ this. parent = parent; 

20 } 

22 public Test getParentO 994 

24 return parent; 

25 } 

27 public int getlterationO | 

II ^ return iteration; 

30 } 

II nublic void addTestSuite (Class testClass) | 

II ^ addTest(new ExtendedTestSuite (testClass) ); J 

35 } 

37 public void addTest(Test test) 

^1 ^ super. addTest (test) ; 

1[? if (test instanceof TestDecorator) 

41 " ^ test = ((TestDecorator) test) ,getTest U , 

4 2 

43 ,^ ^^gg^ instanceof lExtendedTest) 

45 { lExtendedTest extendedTest = 

lIExtendedTest) J^e^st^^^^^^^ (this) ; 

^ } 

public void runTest(Test test, TestResult result) 

adjustlterationO ; 
li super. runTest (test, result); 
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►rotected void adjustlterationO 

if ({parent != null) && (parent instanceof 
lExtendedTest) ) 

int parentlteration = 
( (lExtendedTest) parent) .getlterationO ; 

if (parentlteration 1= previousParentlteratxon) 



{ 



executionCoTint = 0; 
previousParent Iteration 



parentlteration; 

executionCount++ ; 

iteration = ((int) (executionCount / 

this.testCountO)) +1; . ^. ^ ^« ♦./xx n\ 

if ( (executionCount % this.testCountO) 0) 

iteration-- ; 

} 
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;: } 



public String toJUnitString 
return super .toStringO 

} 

public String toStringO 

return hierarchyBranchToString 

} 
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(this); j"^^^ 
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102 
103 
104 
105 
106 } 



protected String hierarchyBranchToString (Test test) 

if ((test i= null) (test instanceof 
lExtendedTest) ) 

^ lExtendedTest extendedProvider = 
(lExtendedTest) test ; 

String hierarchy « 
hierarchyBranchToString (extendedProvider .getParent {) ) ; 

if (hierarchy. length 0 > 0) 

hierarchy = hierarchy + ">"; 

hierarchy ^ hierarchy + 

extendedProvider . getName ( ) ; . , v « v 

if (extendedProvider. getlterationO > 0) 

hierarchy « hierarchy + + 

extendedProvider . get Iteration ( ) ; 
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} 



return hierarchy; 



if (test != null) 

return "?>" + test .toStringO ; 
return " " ; 



FIG.9B 
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I package junit; 
2 

3 import junit .framework. Test ; 

4 import junit . framework. TestCase; 
5 

£ class ExtendedTestCase 

7 extends TestCase implements lExtendedTest 

8 { 

9 private Test parent; 
10 

II /*♦ 

12 * Constructor for JUnitTestCase. 

13 * oparam name 

14 */ 

15 public ExtendedTestCase (String name) 

17 super (name) ; 

18 } 
19 
20 
21 

22 this. parent = parent ; 

23 } 
24 
25 
26 

27 return parent; 

28 } 
29 

30 public int getlterationO 

32 if ((parent != null) && (parent instanceof 
ExtendedTestSuite)) 

33 return ( (ExtendedTestSuite) 

parent) .getlterationO ; 

34 

35 return -1; 

36 } 
37 

3 8 public String toJUnitString () 

39 { 

40 return super. toStringO ; 

41 } 

43 public String toStringO 

44 I 

45 return hierarchyBr anchToSt ring (this) ; 

46 } 
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public void setParent (Test parent) 1 

this. parent = parent; J 

) 

public Test getParentO 1 

return parent; J 
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48 



protected String hierarchyBranchToString(Test test) 



49 { 

FIG. lOA 
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JUNIT L 




JUNIT 


TEST CLASS NAME: 


extendedTests2.TS LUl 


-1 


1 RUN 1 


BIRELOAD CUSSES EVERY RUN 


RUNS: ERRORS: FAILURES: 
0 2 


[fs 1>T4 5>T1 5>B 57*wor introducted at a specific context of t 
ffS 1 > T1 2 > C_2: Errorigjjrouced at a specific context of the test C 




1 RUN 1 






^1202 


▼ 










^FAILURES L TEST HIERARCHY I 






iunit.framework.AssertionFailedError: Error introduced at a specific conte 

atextendedTests2.T1.Bm.iava:61) ^ *o • ha* 
at extended.ExtendedTestSulte.runTest(ExtendedTestSu!te.|ava: 14 
at extendedixtendedTestSultejunTest(ExtendedTestSurte.|ava:l 14) 
atiunit.extensions.TestDecorator.basicRun(TestDecoratorjava:22) 
atjunit.extensions.TestDecorator.run(TestDecorator.java:28) 
at iunit.extensions.RepeatedTest.run(RepeatedTest.java:Z5) 
|at extended.ExtendedTestSuite.runTest(ExtendedTestSuite.java:l 14) 


▼ 










Finished: 0.331 seconds 
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